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RÉSUMÉ. L'environnement Bossa permet la conception d'ordonnanceurs spécifiques offrant ainsi 
une gestion précise de la ressource processeur au sein d'un système d' exploitation général- 
iste. Toutefois, le déploiement conjoint d'une application et de son ordonnanceur suscite des 
problèmes liés à la réservation de la ressource processeur. Dans cet article, nous étudions les 
problèmes dus à ce type de déploiement et proposons quelques solutions. En particulier, nous 
proposons d'établir des contrats de qualité de service et des mécanismes de reconfiguration de 
la hiérarchie d' ordonnanceurs. 

ABSTRACT. Bossa is a framework to develop new processes schedulers in commodity operat- 
ing Systems. Although Bossa enables fine-grained management of the processor through new 
scheduling policies, deploying an application with its own scheduler raises some problems. 
In this paper we study the problems caused when deploying an application and its scheduler 
and to adresse thèse, we propose to establish Quality of Service contracts and mechanisms to 
reconfigure the scheduler hierarchy. 

MOTS-CLÉS : déploiement d'ordonnanceurs, gestion de ressources 
KEYWORDS: scheduler deployment, resource management 
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1. Introduction 

Les applications multimédia sont de plus en plus prisées par les utilisateurs. Ces 
applications sont le plus souvent exécutées sur des systèmes d'exploitations général- 
istes et ont la particularité de devoir répondre à de fortes contraintes de qualité de 
service. Le respect de ces contraintes dans un système d'exploitation nécessite une 
gestion efficace de la ressource processeur par l' ordonnancement de processus. Cepen- 
dant, dans les systèmes d'exploitation généralistes, les ordonnanceurs natifs ne sont 
pas en mesure de garantir, par exemple, le respect des contraintes temporelles nécés- 
saires à la bonne exécution de certaines applications multimédia | JEF 00 IDEM 02l . 
Une solution à ce problème est de développer des ordonnanceurs spécifiques pour 
cette classe d'applications. Toutefois, le développement d'un nouvel ordonnanceur re- 
quiert une bonne connaissance des noyaux de systèmes d'exploitation et des langages 
de programmation bas niveau tels que le C ou l'assembleur. Peu de programmeurs 
possèdent ces deux expertises. 

L'environnement Bossa a été développé pour faciliter la conception et l'intégration 
de nouveaux ordonnanceurs au sein d'un système d'exploitation génér aliste | BATTUS 
ILAW 4b I . Bossa permet d'associer un ordonnanceur spécifique à chaque application 
ou ensemble d'applications partageant les mêmes besoins |LAW 04a |. Cependant, le 
déploiement conjoint d'une application et de son ordonnanceur suscite des problèmes 
liés à l'expression des besoins d'ordonnancement de l'application et du multiplexage 
de la ressource processeur entre les différents ordonnanceurs chargés. Pour adresser 
ces problèmes, nous proposons de mettre en place un protocole de déploiement d'or- 
donnanceurs. A cette fin, nous étudions sous quelles conditions l'intégration d'un or- 
donnanceur spécifique est requise et quelle est l'influence du déploiement d'un ordon- 
nanceur sur le système. 

La section 2 est une brève introduction aux concepts de l'environnement Bossa. 
La section 3 présente les problèmes engendrés par le déploiement d'une application 
avec son ordonnanceur. Quelques solutions à ces problèmes sont présentées en section 
4. La section 5 conclut cet article et présente quelques perspectives. 



2. L'environnement Bossa 

L'environnement Bossa se situe dans le domaine des extensions de systèmes d'ex- 
ploitation où l'on trouve des travaux comme SPIN |BER 95 1 ou Flux OSKit FOR 971 . 
Aussi, Bossa permet de développer et d'intégrer facilement et de façon sûre des or- 
donnanceurs de processus dans un système d'exploitation. 

L'environnement Bossa est organisé autour d'un langage dédié (domain spécifie 
language DSL) et d'un support d'exécution, comme le montre la Figure [2 Le DSL 
offre au programmeur des abstractions de haut niveau dédiées au domaine de l'ordon- 
nancement et facilite ainsi l'implémentation de nouvelles politiques d'ordonnance- 
ment. Le support d'exécution fournit au système d'exploitation une interface facilitant 
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Figure 1 - Environnement Bossa 

l'intégration de composants d'ordonnancement. Dès lors, chaque classe d'applications 
exécutées sur une même machine peut disposer de son ordonnanceur spécifique. 

Toutefois, l'exécution simultanée d'ordonnanceurs au sein d'un même système 
soulève des problèmes de multiplexage de la ressource processeur. Aussi, pour gérer 
l'accès des différents ordonnanceurs à la ressource processeur, il peut s'avérer néces- 
saire de déployer une entité de régulation. Dans l'environnement Bossa, cette entité 
de régulation est implémentée sous la forme d'un ordonnanceur virtuel qui peut être 
vu comme un ordonnanceur d'ordonnanceurs IL AW 04al . L'association d'un ordon- 
nanceur virtuel et d'un ou plusieurs ordonnanceurs constitue une hiérarchie d'ordon- 
nanceurs comme le montre la Figure[2] La construction d'une hiérarchie, dans l'en- 
vironnement Bossa, se fait de façon explicite. Aussi, une application est en mesure 
de déployer son propre ordonnanceur via l'utilisation d'une bibliothèque de fonctions 
ad-hoc, comme le montre la Figure|2] 
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Figure 2 - Exemple du déploiement actuelle d'une application et son ordonnanceur 
dans l'environnement Bossa 



3. Problèmes engendrés par le déploiement d'une application et de son 
ordonnanceur 

Le modèle de déploiement d'une application et de son ordonnanceur dans l'envi- 
ronnement Bossa exhibe les limitations suivantes : 

- les conditions d'exécution de l'application sont définies à priori par le program- 
meur sans tenir compte de l'environnement d'exécution, 

- le système ne vérifie pas la pertinence du chargement d'un nouvel ordonnanceur, 
c'est-à-dire s'il n'existe pas déjà un ordonnanceur sur lequel l'application est en 
mesure de s'exécuter, 
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- le système ne vérifie pas lors du chargement d'un ordonnanceur que les garanties 
offertes initialement aux applications existantes sont encore respectées. En effet, l'exé- 
cution simultanée de plusieurs ordonnanceurs sur la même ressource processeur en- 
traîne irrémédiablement des problèmes de partage. 

Pour garantir le déploiement cohérent d'une application et son ordonnanceur avec 
l'environnement existant, le système doit offrir des mécanismes pour répondre aux 
limitations actuelles. 

4. Solutions aux problèmes de déploiement 

Nous introduisons les notions de classe d'applications et de services d'ordon- 
nancements. Aussi, pour valider la pertinence du chargement d'un nouvel ordon- 
nanceur, nous proposons de mettre en place un protocole de communication | D EM 021 . 
Dans ce protocole, une application peut spécifier la classe à laquelle elle appartient, 
ses besoins en matière d'ordonnancement ainsi que vérifier l'existance d'un service 
d'ordonnancement compatible dans la hiérarchie d'ordonnanceurs. Pour préserver les 
garanties d'ordonnancement lors du chargement d'un nouvel ordonnanceur dans une 
hiérarchie, nous proposons d'utiliser un algorithme de construction de hiérarchies. 
Pour expliciter ces solutions, nous décrivons tout d'abord une approche introduite par 
Regehr et Stankovic et proposons ensuite quelques extensions à ce modèle [R EG Oll . 

4.1. Approche de Regehr et Stankovic 

Regehr et Stankovic ont mis en place une caractérisation des services d'ordon- 
nancement qui permet d'évaluer et de valider l'utilisation de la ressource processeur 
au sein d'une hiérarchie d'ordonnanceurs. Aussi, Regehr et Stankovic proposent qu'un 
ordonnanceur établisse un contrat de qualité de service avec l'entité qu'il ordon- 
nance (application ou ordonnanceur). Un contrat de service s'exprime selon la syn- 
taxe TYPE [param] , où TYPE représente le service d'ordonnancement (ordonnanceurs 
temps réel, à proportion...) et [param] représente le quota de ressource processeur 
garanti par le contrat. La combinaison des différents contrats ébauche le squelette 
d'une hiérarchie, qui est ensuite construite par un algorithme spécifique. 

Ce modèle de déploiement permet de résoudre partiellement i) le problème de né- 
gociation de l'intégration d'un ordonnanceur en offrant une classification des ordon- 
nanceurs par type de service d'ordonnancement et ii) le problème de reconfiguration 
dynamique de la hiérarchie en proposant un algorithme de composition de hiérarchie 
d'ordonnanceurs. 

4.2. Extension des travaux de Regehr et Stankovic 

Le modèle de déploiement d'ordonnanceurs proposé par Regehr et Stankovic ne 
permet pas d'établir une demande de ressources au niveau global comme le montre 
la figure [3] Aussi, la ressource processeur concernée par ce contrat est limitée à la 
ressource disponible localement au niveau de l'ordonnanceur. De plus, ce modèle ne 
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Figure 3 - Limitation de la ressource processeur au niveau local 



répond pas aux problèmes de négociation de l'intégration d'un ordonnanceur spéci- 
fique. Enfin, l'algorithme de construction interrompt la réalisation de la hiérarchie s'il 
est impossible de respecter l'un des contrats. Par conséquent, nous proposons : 

- de mettre en place un protocole pour autoriser ou non une application à charger 
son ordonnanceur. Ce protocole est le suivant : une application souhaitant s'exécuter 
doit exprimer ses besoins d'ordonnancement en utilisant le modèle sémantique défini 
par Regehr et Stankovic. Cette expression de besoins est alors utilisée par le système 
pour rechercher dans la hiérarchie s'il existe un service d'ordonnancement compatible. 
Dans le cas contraire, le système charge le composant d'ordonnancement spécifique à 
l'application, 

- d'étendre l'algorithme de composition d'une hiérarchie d'ordonnanceurs utilisé 
par Regehr et Stankovic en remplaçant la condition d' arrêt de l' algorithme par une ten- 
tative de réallocation de la ressource processeur entre tous les ordonnanceurs présents. 
Cette extension permet au système d'essayer de répondre aux besoins exprimés par 
l'application. 

Ces deux étapes du déploiement sont illustrées par la Figure|3] 
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Figure 4 — Algorithme de déploiement d'un ordonnanceur 
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5. Conclusion 

Dans cet article nous avons présenté le principe du déploiement d'une application 
avec son ordonnanceur dans un système d'exploitation généraliste et décrit les prob- 
lèmes engendrés. Pour les problèmes non encore adressés par l'utilisation de l'envi- 
ronnement Bossa nous avons proposé i) de valider la pertinence du chargement d'un 
nouvel ordonnanceur et ii) de vérifier le maintien des contraintes d'ordonnancement 
lors du chargement d'un nouvel ordonnanceur dans la hiérarchie. 

Nous souhaitons maintenant implémenter ces solutions dans F environnement Bossa. 
De plus, nous nous proposons d'étudier les possibilités d'adaptabilité de l'application, 
afin qu'elle puisse revoir ses besoins d'ordonnancement si ceux-ci ne peuvent être 
satisfaits. 
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